package Day_0207.Redis;

/**
 * @author zxc
 * @date 2023/02/07 22:53
 **/
public class Redis_Database {
    public static void main(String[] args) {
        /**
         * 缓存和数据库哪个先进行更新？
         * ===》
         * 1. 写请求过来，将写请求缓存到缓存队列中，并且开始执行写请求的具体操作;
         * （1）删除缓存中的数据;
         * （2）更新数据库;
         * （3）更新缓存;
         *
         * 2.删除缓存失败的情况 ：
         * 如果在更新数据库过程中，又来了个读请求，将读请求再次存入到缓存队列中，
         * （可以搞n个队列，采用key的hash值进行队列个数取模hash%n，落到对应的队列中，队列需要保证顺序性）
         * （1）顺序性保证等待队列前的写请求执行完成，才会执行读请求之前的写请求;
         * （2）删除缓存失败，直接返回，此时数据库中的数据是旧值，并且与缓存中的数据是一致的，不会出现缓存一致性的问题。
         *
         * 3. 删除缓存成功 && 更新数据库失败的情况 ：
         * （1）写请求删除缓存成功，则更新数据库，
         * （2）如果更新数据库失败，则直接返回，写请求结束，
         * （3）此时数据库中的值依旧是旧值，读请求过来后，发现缓存中没有数据， 则会直接向数据库中请求，
         * （4）同时将数据写入到缓存中，此时也不会出现数据一致性的问题。
         *
         * 4. 删除缓存成功 && 更新数据库成功 && 更新缓存成功/失败
         * （1）更新数据成功之后，再更新缓存，如果此时更新缓存失败，则缓存中没有数据，数据库中是新值 ，写请求结束，
         * （2）此时读请求还是一样，发现缓存中没有数据，同样会从数据库中读取数据，并且存入到缓存中，
         * （3）其实这里不管更新缓存成功还是失败， 都不会出现数据一致性的问题。
         *
         * ===》
         * 总结 :
         * （1）解决了数据不一致的问题，主要是使用了串行化，每次操作进来必须按照顺序进行。
         *  ===》 保证了请求操作的有序性;
         *  （即，后续的读请求操作必然要等待之前的写操作完成;）
         *
         * （2）如果某个队列元素积压太多，可以针对读请求进行过滤，提示用户刷新页面，重新请求。
         *
         *
         * 潜在问题 ：
         * 1，请求时间过长，大量的写请求堆压在队列中，一个读请求来得等都写完了才可以获取到数据;
         * 2，读请求并发高;
         * 3，热点数据路由问题，导致请求倾斜;
         *
         */
    }
}
